A Transport Layer Security (TLS) session as well as its predecessor, the Secure Sockets Layer (SSL), are cryptographic protocols that provide secure communications on the Internet or other networks for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. There are slight differences between SSL and TLS, but they are essentially the same.
TLS provides endpoint authentication and communications privacy over untrusted networks using cryptography. Typically, only the server is authenticated (i.e., its identity is ensured) while the client remains unauthenticated; this means that the end user (whether an individual or an application, such as a Web browser) can be sure with whom it is communicating. The next level of security in which both ends of the “conversation” are sure with whom they are communicating is known as mutual authentication. Mutual authentication requires public key infrastructure (PKI) deployment to clients unless TLS-PSK or the Secure Remote Password (SRP) protocols are used, which provide strong mutual authentication without needing to deploy a PKI.
TLS involves three basic phases: (1) Peer negotiation for algorithm support; (2) Key exchange and authentication; and (3) Symmetric cipher encryption and message authentication.
During the first phase, the client and server negotiate cipher suites, which determine the ciphers to be used, the key exchange and authentication algorithms, as well as the message authentication codes (MACS). The key exchange and authentication algorithms are typically public key algorithms, or as in TLS-PSK pre-shared keys could be used. The message authentication codes are made up from cryptographic hash functions using the HMAC construction for TLS, and a non-standard pseudorandom function for SSL.
SSL is a handshake with two-way authentication that utilizes digital certificates. A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.
The handshake begins when a client connects to a TLS-enabled server requesting a secure connection, and presents a list of supported ciphers and hash functions. From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision. The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA), and the server's public encryption key, normally included in the server's digital certificate. The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is authentic (not revoked) before proceeding. When generating the session keys used for the secure connection, the client encrypts a random number with the server's public key, and sends the result to the server. Only the server can decrypt it (with its private key): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data.
From the random number, both parties generate key material for encryption and decryption. This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes. If any one of the above steps fails, the TLS handshake fails, and the connection is not created.
Digital certificates are commonly used in cases where browsers are involved in TLS connections. There are also cases where TLS connections do not involve using browsers. Browsers are typically used when a user wants to buy something from a website (e.g., Amazon.com). When the user reaches the check-out page on the amazon.com web site, a secure connection is established. (The “lock” is displayed in the browser.) This secure connection uses the TLS protocol, which requires the use of small files called digital certificates that are exchanged during TLS establishment. The website (Amazon.com in this example) sends its certificate to the user's browser and the browser validates the certificate. Validation of the certificate is typically accomplished by checking two things: (1) that the certificate was issued to a web site whose address appears in the browser's address bar and (2) that the signature of the certificate is valid.
A CA issues the digital certificate for a web site. When the CA issues a certificate for a web site, the CA computes a digital signature for the certificate and stores the result in the certificate being issued. This process involves using encryption technology and employs an encryption key.
When the browser receives the digital certificate from amazon.com, the browser must be able to validate its signature. To do this, the browser needs an encryption key related in a special way to the one used by the CA to create the signature in the first place. This encryption key is provided in another certificate issued by the certificate authority; this certificate is a special certificate, called a root certificate. The browser generally comes pre-loaded from the software provider (e.g., Microsoft® if Internet Explorer® is used as the browser) with a number of such certificates. These certificates are called trusted certificates.
Once the browser has access to the certificate from the CA used to sign the amazon.com certificate it can use that trusted certificate to obtain the encryption key needed to verify the signature on certificates received from amazon.com, for example.
The browser finds the signature is valid if it computes the same hash value that is stored in the certificate, determines that the ISSUED TO field in the certificate has the same value as the web site in the browser's address bar (i.e., www.amazon.com) and further identifies that the certificate was issued by the trusted CA. After making these determinations, the browser will allow the user to continue with checkout.
Many TLS connections, on the other hand, are server to server and do not involve a human user at a browser. In such a case where a browser is not involved, a customer network may include many servers interconnected with one another. Typical customer networks may include up to hundreds of servers connected to one another in various configurations and via various protocols.